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PPP for Data Compression in Data Circuit-—Terminating Equipment (DCE) 
Status of This Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


The Point-to-Point Protocol (PPP) [1] provides a standard method for 

transporting multi-protocol datagrams over point-to-point links. PPP 
defines an extensible Link Control Protocol, and proposes a family of 
Network Control Protocols for establishing and configuring different 

network-layer protocols. 


The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a 
standard method for encapsulating and transporting serial data over a 
PPP link. The PPP Compression Control Protocol [3] provides a 
standard method for selecting and using a compression protocol to 
provide for data compression on a PPP link. 


This document defines a specific set of parameters for these 
protocols and an LCP extension to define a standard way of using PPP 
for data compression of serial data in Data Circuit-Terminating 
Equipment (DCE). 
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Introduction 


This document is a product of the TR30.1 ad hoc committee on 
compression of synchronous data. It represents a component of a 
proposal to use PPP to provide compression of synchronous serial data 
in DSU/CSUs. 


PPP [1] has three main components: 
1. A method for encapsulating multi-protocol datagrams. 


2. A Link Control Protocol (LCP) for establishing, configuring, 
and testing the data-link connection. 


3. A family of Network Control Protocols for establishing and 
configuring different network-layer protocols. 


In addition to providing support for multi-protocol datagrams, the 
Point-to-Point Protocol (PPP) [1] has defined an effective and robust 
negotiating mechanism that can be used on point to point links. When 
used in conjunction with the PPP Compression Control Protocol [3] and 
one of the PPP Compression Protocols [4], PPP provides an 
interoperable method of employing data compression on a point-to- 
point link. 


The PPP Serial Data Transport Protocol (PPP-SDTP) and the PPP Serial 
Data Control Protocol (PPP-SDCP) [2] have been developed to allow 
serial data to be carried within a PPP packet. PPP-SDTP uses a 
terminal adaption header based on that of ITU-T Recommendation V.120 
[5]. 


-l. Specification of Requirements 


In this document, several words are used to signify the requirements 
of the specification. These words are often capitalized. 


MUST This word, or the adjective "required", means that the 
definition is an absolute requirement of the specification. 


MUST NOT This phrase means that the definition is an absolute 
prohibition of the specification. 


SHOULD This word, or the adjective "recommended", means that there 
may exist valid reasons in particular circumstances to 
ignore this item, but the full implications must be 
understood and carefully weighed before choosing a 
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different course. 


This word, or the adjective "optional", means that this 
item is one of an allowed set of alternatives. An 
implementation which does not include this option MUST be 
prepared to interoperate with another implementation which 
does include the option. 


1.2. Terminology 


This document frequently uses the following terms: 


datagram 


frame 


packet 


peer 


The unit of transmission in the network layer (such as IP). 
A datagram may be encapsulated in one or more packets 
passed to the data link layer. 


The unit of transmission at the data link layer. A frame 
may include a header and/or a trailer, along with some 
number of units of data. 


The basic unit of encapsulation, which is passed across the 
interface between the network layer and the data link 
layer. A packet is usually mapped to a frame; the 
exceptions are when data link layer fragmentation is being 
performed, or when multiple packets are incorporated into a 
single frame. 


The other end of the point-to-point link. 


Silently discard 


This means the implementation discards the packet without 
further processing. The implementation SHOULD provide the 
capability of logging the error, including the contents of 
the silently discarded packet, and SHOULD record the event 
in a statistics counter. 


2. Modes of Operation 


This document provides for three modes of operation for DCE devices: 
Mode-0 represents transparent operation; Mode-1 a simplified, 
predefined compression format; and Mode-2, a full PPP implementation 
providing compression of serial data. 


Mode-0 represents the operating mode of currently deployed DCEs that 
operate in transparent mode, without any DCE-to-DCE protocols. 
Mode-1 devices implement data compression upon detecting an initial 


handshake, 


which is implemented via an newly defined LCP 


Configuration Option called the DCE-Identifier. The DCE-Identifier 
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is used both to distinguish DCE devices from PPP bridges and routers, 
and to all Mode-1 and Mode-2 DCE devices to interoperate, via its 
Mode parameter. In Mode-1, the parameters of operation are not 
negotiable. Mode-2 devices implement the full LCP state machine and 
are therefore capable of negotiating alternatives to the default set 
of paramaters and options. Mode-2 devices must also support Mode-1 
operation, and fall-back to such operation when connected to a Mode-1 
device. The mechanism of the Mode-1/Mode-2 handshake is given in 
Section 7. 


3. PPP Link Control Protocol Extension 


The use of PPP in Compression DCE requires the use of an additional 
LCP Configuration Option: 


25 DCE-Identifier 


DCE-Identifier 


The presence of this option indicates that the system sending it 
is Data Circuit-Terminating Equipment (DCE) that desires to 
establish a serial data compression link. 


0 1 2 

Od 2734S: Oe 7 88 OO 23-4? 5-67 8 9402 do 2 3 

a 
| Type | Length | Mode | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type 


25 


I Mode-1 (No Additional Negotiation) 
2 Mode-2 (Full PPP Negotiation and State Machine) 


4. Required PPP Elements 
Unlike PPP’s native bridge/router environment, the minimum 


requirement for use of PPP in DCE equipment is not simply 
interoperability, but rather interoperability with effective data 
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compression. With this in mind, it is desirable to specify a minimum 
PPP feature set, that is somewhat different than that of a normal PPP 
bridge/router requirement. 


This different feature set includes: support for compression, support 
of a single default compression algorithm, support of Protocol-Field 
compression, support of Address-—and-Control-Field-Compression, 
support of PPP-SDTP, etc. 


The minimum feature set includes the following protocols: 


PPP Link Control Protocol (Mode-1 must include a subset) [1] 
PPP in HDLC-like Framing [6] 

PPP Compression Control Protocol (Mode-2 only) [3] 

PPP LZS-DCP Compression Protocol [4] 

PPP Serial Data Transport Protocol [2] 

PPP Serial Data Control Protocol (Mode-2 only) [2] 


The Stacker-LZS algorithm from Stac Electronics was chosen as the 
default compression algorithm for DCE devices. This decision was 
made by the TR30.1 ad hoc based on licensing issues (agreeing to 
non-discriminatory and reasonable terms), compression ratios, its 
efficient use of processor and memory resources, and speed 
scalability. A compression protocol incorporating in-band 
synchronization signaling was defined for the Stacker algorithm and 
selected for the default compression protocol. This protocol is 
known as the PPP LZS-DCP Compression Protocol [4]. Although the PPP 
LZS-DCP Compression Protocol specifies a number of formats and 
history management options, only the default format with a single 
history must be implemented. 


4.1. Required Configuration Options and Parameters 


To ensure that implementations are able to interoperate with 
effective data compression, a required set of Configuration Options 
are specified. These Options are assumed in Mode-1, and are 
negotiated in Mode-2, using the standard PPP negotiation state 


machine. (Mode-1 uses a fixed packet format with a predetermined set 
of values for LCP, LZS-DCP, and SDTP Configuration 
Options/parameters. The required values listed in this section are 


the predefined values.) 


The following LCP Configuration Options [7] MUST be supported: 


Maximum—Receive-Unit 1550 
Address/Control-Field-Compression Yes 
Protocol-Field-Compression Yes 
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The following CCP Configuration Option MUST be supported: 
Compression-Type 23 (LZS-DCP) 


The following default LZS-DCP Configuration Options MUST be 
supported: 


Check-—Mode 3 (sequence + LCB) 
History-Count 1 (single history) 
0 


Process—Mode (None) 


The default SDTP/SDCP Configuration Options MUST be supported. They 


are: 
Packet-Format: Header-Last 
Header-Type: H-Only 
Multiple-Packets: Off 
Multi-Port: off 
Transport-Mode: HDLC-Synchronous 
Maximum-Frame-Size: 10,000 bytes 
Allow-Odd-Frames: off 
FCS-Type: Transparent-Transport 
Flow-Expiration-Time: 100 


5. Mode-1 Requirements 


DSUs that use only Mode-1 (non-negotiate mode) use only a 
predetermined set of PPP packets. In addition to a fixed data packet 
format, two fixed formats are used to differentiate between Mode-1 
devices and Mode-0 (transparent) devices. Mode-1 devices are 
designed to operate using compression if a peer has the same 
capability, or revert to transparent operation (Mode-0) if the peer 
does not support standard compression. 


Mode-1 devices use LZS-DCP Compression Packets as specified in [4]. 
These packets include the capabilities of DCP: Reset-Request and 
Acknowledge, Compressed/Transparent, etc. Since the packets include 
signalling, these packets can be sent with an empty data field to 
signal a reset request if no data packets are ready for piggy-backed 
signalling. 


Exactly one LZS-DCP packet is encapsulated in the PPP Information 
field, where the PPP Protocol field indicates type OOFD (Compression 
Protocol). Exactly one SDTP packet is transported by each LZS-DCP 
data packet. 
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Operation in Mode-1 implies a set of predetermined values for LCP, 
LZS-DCP, and SDTP configuration options and parameters, using the 
values listed in the preceding section. 


The following PPP packets are permitted and recognized: 


LCP Configure-Request with DCE Mode-1 Configuration Option 
LCP Configure-Ack with DCE Mode-1 Configuration Option 
LZS-DCP Packet with the data field containing an SDTP packet 
LZS-DCP Packet with an empty data field 


Protocol-Field-Compression and Address-and-Control-Field-Compression 
is used on all packets except the handshake packets (LCP packets). 


Any Mode-1 or Mode-2 DCE that receives a Mode-1 request MUST 
Acknowledge the request. 


5.1. Detailed Mode-1 Example 


Detailed Example when using Mode-1 on a point-to-point leased or 
circuit switched link (using PPP in HDLC-like Framing [6]) (data 
shown is after flags and inserted 0s are removed; lower case letters 
and numbers represent actual values, uppercase represent data fields 
whose values may vary from packet to packet; parentheses surrounding 
a field indicate that the field may not be present in all packets of 
that type): 


LCP Configure-Request: 
Config. Opt. 


Addr. Ctl. PID Code ID Length Type Lngth Mode 
+—----+----+------- +—----+----+------- +----+----+----+----- + 
| ££ | 03 | co 21 | o1 | oo | o0 07 | 21 | 03 | 01 | Fcs 
+----+----+------- +----+----+------- +----+----+----+----- + 


LCP Configure-Ack: 


Config. Opt. 


Addr. Ctl. PID Code ID Length Type Lngth Mode 
+----+----+------- +----+----+------- +----+----+----+----- + 
| ££ | 03 | co 21 | 02 | oo | o0 07 | 21 | 03 | 01 | Fcs 
+----+----+------- +----+----+------- +—----+----+----+----- + 
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The DATA field contains a compressed or uncompressed SDTP-PDU. 

The LCB field is only present on a packet containing compressed 
data. The Sequence Number and Data fields are only present on 

packets that contain data. 


4+----+------ +----+ 
SDTP-PDU: | 49 | DATA | HD | 
4+----+------ +----+ 

6. Initial Handshake Operation 


When a unit is powered up, or when the lower layer signals that the 
peer has gone out of service and returned, the handshake procedure is 
initiated. The handshake procedure for Mode-1 and Mode-2 devices is 
described below. 


Mode-1: 
When starting Mode-1, each DCE sends out an LCP Configure-Request 


packet containing only the DCE-Identifier LCP Configuration Option 
described in Section 3, with the with the Mode Field set toa 


value of 1. When a DCE device receives such a packet, it must 
answer with an LCP Configure-Ack packet. In each of these 
packets, the identifier field is set to 0. If the originator of 


the Configure-Request packet does not receive a Configure-Ack 
response within a user configurable time T1, the unit MUST revert 
to transparent (Mode-0) operation. 


Mode-2: 


A Mode-2 device will first try to operate in Mode-2 by starting 
PPP normally, following the state machine described in [1]. The 
LCP Configure-Request MUST include the DCE-Identifier 
Configuration Option with the Mode Field set to 2. If the unit 
receives a Configure-Reject Packet Containing the DCE-Identifier, 
the unit MUST revert immediately to transparent (Mode-0) 
operation. If the LCP state machine times out because a response 
was not received in user configurable time T2, or if a Mode-1 
Configuration-Request packet is received, the unit attempts to 
operate in Mode-1 by following the procedure listed above, 
ultimately reverting to Mode-0 operation if the Mode-1 procedure 
times out. 


In either case, the unit is not prohibited from sending multiple 
Configuration-Request packets before the applicable timer (T1, T2) 
expires. A unit may also initiate the handshake procedure at any 
time. 


Schneider & Venters Informational [Page 8] 


RFC 1976 PPP DCE August 1996 


7. Security Considerations 
Security issues are not discussed in this memo. 
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